WASI 0.2: la nueva interfaz estandar para WebAssembly

javi
Cubos modulares conectados representando componentes de software

WebAssembly ha pasado de ser “JavaScript pero más rápido en el navegador” a una plataforma seria para ejecutar código portátil fuera del browser. La pieza clave de esa transición es WASI (WebAssembly System Interface), el estándar que define cómo módulos WASM acceden a recursos del sistema (filesystem, red, hora). En 2023 se aproxima la finalización de WASI Preview 2, una reescritura sustancial respecto a Preview 1. Cubrimos qué cambia, por qué y qué impacto tendrá.

El problema con Preview 1

WASI Preview 1 (publicado en 2019) hizo posible WebAssembly fuera del navegador. Pero a medida que el ecosistema maduró, sus limitaciones se hicieron evidentes:

  • Modelo POSIX-like. Diseñado pensando en filesystem y syscalls al estilo Unix. No encaja bien con casos modernos como cloud functions, edge computing o IoT.
  • No componibilidad. Dos módulos WASM no podían fácilmente “componerse” entre sí — comunicarse en tipos ricos, no solo bytes.
  • Sin tipos ricos a nivel de interfaz. Solo enteros, floats, punteros y memoria. Strings, structs, listas requerían serialización manual.
  • Capabilities limitadas. Concedías acceso al filesystem entero, no a recursos granulares.

Preview 2 reescribe la base para resolver estos problemas, manteniendo retrocompatibilidad con Preview 1 durante la transición.

El Component Model y WIT

La novedad central es el Component Model: módulos WASM como componentes con interfaces tipadas explícitamente, capaces de componerse entre sí en runtime.

Las interfaces se describen en un lenguaje llamado WIT (WebAssembly Interface Type):

package jacar:examples;

interface logger {
    log: func(message: string);
    levels: enum { debug, info, warning, error }
}

world my-app {
    import logger;
    export run: func();
}

Esto declara un componente que importa una interfaz logger y exporta una función run. WIT soporta tipos como string, record (struct), variant (sum type), list, option, result. Mucho más expresivo que enteros y memoria cruda.

La consecuencia: dos componentes WASM compilados desde lenguajes distintos (Rust + Go + JavaScript) pueden hablar entre sí pasando structs ricos sin serialización manual. Es la base para un ecosistema de componentes reusables.

Capabilities granulares

Preview 2 introduce un modelo de capabilities mucho más fino. En vez de “el módulo puede acceder al filesystem”, concedes acceso a:

  • Un directorio específico, para lectura solo.
  • Un socket TCP a un host concreto, no toda la red.
  • Una variable de entorno concreta, no getenv() libre.
  • Un timer del sistema, sin acceso a clocks de wall time.

Esto encaja mucho mejor con casos como edge functions o plugins en aplicaciones host, donde quieres ejecutar código no-confiable con permisos mínimos.

Estado en 2023

A finales de 2023, WASI Preview 2 está en fase de release candidate. La especificación oficial 0.2 se espera estabilizada para principios de 2024.

Implementaciones de runtime que ya soportan o están añadiendo soporte:

  • Wasmtime (Bytecode Alliance) — implementación de referencia, tracking del estándar.
  • wasmer — soporte progresivo.
  • WasmEdge — foco en edge y cloud-native.
  • Spin (Fermyon) — framework para apps WASM con soporte temprano de Component Model.

Toolchains de lenguaje añadiendo soporte:

  • Rust vía cargo-component.
  • JavaScript vía jco.
  • Python vía componentize-py.
  • Go vía tinygo (parcial) y projects experimentales.

Casos de uso que se desbloquean

Preview 2 + Component Model habilitan casos donde WASM tradicional rechinaba:

  • Plugins seguros en aplicaciones host. Editores, servidores HTTP (módulos de Apache/Nginx en WASM), bases de datos extensibles. Capabilities granulares evitan el riesgo de plugins maliciosos.
  • Serverless / edge functions de verdadera multilingüe. Una function en Python puede llamar a otra en Rust sin serializar a JSON.
  • Microservicios en WASM. Componentes pequeños componibles que se ejecutan en runtimes ligeros (más rápidos de arranque que contenedores).
  • Smart contracts portables. Algunos blockchains (Substrate, NEAR) ya usan WASM; el component model facilita la composición.
  • Embedded ML. Modelos pequeños empaquetados como componente WASM, ejecutables en cualquier runtime que soporte el estándar.

Limitaciones que quedan

Aún en 2023:

  • Threading y concurrencia son áreas con propuestas pero aún no estandarizadas.
  • Garbage collection (importante para lenguajes como Java, C#, Python) en propuesta separada (WASM-GC), aún no integrada.
  • Performance en algunos lenguajes JIT-compiled puede no igualar runtime nativo.
  • Tooling de debug sigue maduración — debuggers, profilers no son tan ricos como para código nativo.
  • Adopción de runtime en casos masivos (hyperscale serverless) aún incipiente.

Por qué te interesa aunque no escribas WASM

Como ingeniero que no toca WebAssembly directamente, el ecosistema WASM/WASI es relevante porque:

  • Edge functions de Cloudflare, Fastly y otros corren WASM internamente.
  • Plugins de varias herramientas (Envoy proxy, OPA, Istio) son WASM.
  • Bases de datos como SQLite y futuras versiones de Postgres exploran extensiones en WASM.
  • Smart contracts y blockchain con soporte WASM crecen.

Conocer la dirección del estándar (Preview 2, Component Model) ayuda a entender por qué ciertos productos toman decisiones de arquitectura y a anticipar capacidades que llegarán.

Conclusión

WASI Preview 2 es el paso de WebAssembly hacia “plataforma seria” fuera del navegador. El Component Model con interfaces tipadas y capabilities granulares resuelve limitaciones reales que han frenado adopción. La estandarización completa llegará en 2024, pero el momento de empezar a explorar es ahora — sobre todo si construyes herramientas que se beneficiarían de plugins, edge computing o ejecución segura de código no-confiable.

Síguenos en jacar.es para más sobre WebAssembly, edge computing y evolución de plataformas.

Entradas relacionadas